無論是開發Android or Kotlin，筆者覺得學會版本控制都是一個很必要的前提，筆者開始工作後就是接觸Git，因此就特別介紹Git給大家了，當然Git這個主題在2013鐵人賽就已經Will 保哥專門講解每個步驟了，連結在此。
網路上也有非常多的資源去教學如何上手Git，表列如下：
因此因此，筆者在這篇只想寫Git的觀念，詳細細節請去上列頁面學習xD
如果讀者有玩以前的單機遊戲的經驗的話，應該對存檔，讀檔不陌生。
以前玩遊戲玩到一個段落的時候都會有一個存檔的時間點，之後如果不幸死掉了，
就可以回到這裡繼續玩，就好比馬力歐每一關卡都會自動存檔，
攻略到一半死掉的時候會從關卡的開頭開始玩，筆者認為這就是版本控管的核心概念。
Git是一個如何保存這個時間點的開發狀態，
然後從這裡往下開發，開發發現錯誤需要讀檔的時候，
又可以回頭讀取之前的保存點，這個方面做得很好的軟體。
在Git裡面，checkout可以視為讀檔，commit則視為存檔，開發了一陣子就可以commit一次，
需要的時候就可以checkout 回原來存取的commit點，branch則可以視為不同的存檔，
以前筆者玩遊戲遇到分歧點的時候，都會開一個branch，試圖玩完所有的遊戲隱藏劇情。
而多人協作的時候，我們就需要一個存讀檔的倉庫(Repositories)，
而全世界最常聽到的就是GitHub，而其實其他的Git Repositories的平台也很多，
例如BitBucket, Gitlab，也有人專門撰文比較這些平台的優劣：
了解Repositories了以後，我們要怎麼共同協作呢？
就會用到push，你可以將你的存檔(branch) push 到某一個共同的repositories上，
然後另一個開發者將你的存檔(branch) 從repositories上 pull下來，
他就能從你最後開發的時間點繼續接手開發了。
那如果我們玩遊戲有不同的地方怎辦？
就需要合併marge，這個功能會將你的兩條branch 合為一條，
git會依照檔案最後的修改timestamp初步的決定哪一個檔案是開發者會需要的，
而他不能判斷的地方就會標示 conflict，然後讓開發者決定要用哪一段程式，
merge如果conflict 的地方過多，都會由需要合併的兩個工程師坐下來討論，
一起merge，所以筆者認為最好的方式是修改了一部分，確認功能完整，就上傳讓其他協作者merge。
接著，我想談談Git Flow，一樣先提供上網路資源列表：
什麼時候會用到Git Flow?
誠如剛剛筆者所說的，我們很多情況會push 自己的branch到repositories上，
也會去pull別人的branch下來繼續開發，那哪個存檔才是我們真正可以發布出去給顧客使用的呢？
因此就有人專門為了這種存檔的流程定義了一套系統，就稱為Git flow，
原則上所有人都可以自己將自己開發的branch從develop上分歧為一個feature/[every name you want]，
而當開發好以後，就由團隊裡的release manager將其merge 回develop，
筆者聽過有些團隊是Sr. Engineer去merge，有些則是PM，
也有公司完全交由團隊自己去control，但大多數的情況，筆者認為 follow Git Flow是一個比較好的協作方式。
最後我想介紹筆者用的GUI：GitKraken
為甚麼會特別提名這個Git GUI呢？因為很方便使用又很美觀！
這個GUI可以用左鍵連點兩下就幫你checkout 到某個你要的branch，
merge conflict 也會幫你標示哪些是需要你選擇修正的檔案，
筆者之前使用sourceTree跟GUI Clients，一直覺得畫面不夠美觀，
使用起來也很不直覺，只是sourceTree行之有年，功能比較齊全…
直到用GitKraken了以後，發現回不去了
最後，學習Git筆者建議的路線還是從git command Line開始學習，
先學習如何用command line去操作Git，等到熟悉了以後，再切成使用GUI，
才能使用的得心應手，Repositories出問題的時候，也才會知道如何回去操作修正，
很多特別的問題GUI都是無法幫忙的，畢竟Git GUI對Git來說就只是一個很方便的輔助工具，
但用的好可以節省掉非常多的時間，因此筆者也十分推薦學習使用一套好的GUI去加速開發。
希望經過這篇的學習後，大家都會更喜歡用Git！
本文同步刊登在Medium上，連結在此。
iThome鐵人賽
看影片追技術